The mis-namespaced-model warning added in #1356 assumed "explicit
SEARCH_RERANK_URL" implies "not the gateway". Pinning the URL to the
gateway's own /v1/rerank is a legitimate configuration — it is how you
fix the endpoint while still using the gateway — and the `local/` routing
prefix is correct there. The warning fired on that working setup, which
is how operators learn to ignore warnings.
Found by running the gateway-free rerank path end to end against a real
login-flow stack.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The mis-namespaced-model warning added in #1356 assumed "explicit
SEARCH_RERANK_URL" implies "not the gateway". Pinning the URL to the gateway's own/v1/rerankis a legitimate configuration — it is how you fix the endpoint while still using the gateway — and thelocal/routing prefix is correct there.So the warning fired on a working setup, which is how operators learn to ignore warnings.
How it was found
Running the gateway-free rerank path end to end against a real login-flow stack. The server logged:
…while reranking was working correctly, because
SEARCH_RERANK_URLwas the gateway's own/v1/rerank.The fix
Warn only when the URL is somewhere other than the configured gateway. Verified silent on the live deployment afterwards, with
rerank_available: trueand the endpoint still resolving to the explicit URL.Test coverage
Added
test_rerank_url_pointing_at_the_gateway_is_quietalongside the existing quiet-case test, so both sides of the boundary are pinned: a genuinely direct endpoint (http://infinity:7997/rerank+local/…) still warns; a gateway-pinned URL does not.No API surface change, so no e2e/contract tier applies. 108 tests in
tests/unit/test_config.pypass;ruff,ruff format,tyclean.This PR was generated with the help of AI, and reviewed by a Human